home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 7116 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.5 KB  |  131 lines
  1. Path: munta.cs.mu.OZ.AU!fjh
  2. From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
  3. Newsgroups: comp.lang.misc,comp.lang.perl.misc,comp.lang.tcl,comp.lang.c,comp.lang.java
  4. Subject: Re: Relative Speed of Perl vs. Tcl vs. C [indentation]
  5. Date: 19 Feb 1996 04:02:31 GMT
  6. Organization: Comp Sci, University of Melbourne
  7. Message-ID: <4g8son$gmd@mulga.cs.mu.OZ.AU>
  8. References: <4g0bd6INNn9j@keats.ugrad.cs.ubc.ca> <4g1h0a$l72@orac.mon.rnb.com> <MARKT.96Feb16162033@atlas.harlqn.co.uk>
  9. NNTP-Posting-Host: munta.cs.mu.oz.au
  10.  
  11. markt@harlqn.co.uk (Mark Tillotson) writes:
  12.  
  13. >hdavies@kzin.mon.rnb.com (Hugh J.E. Davies) wrote:
  14. >
  15. > > I actually like code that structures blocks by indentation, since it
  16. > > makes writing folding editors simple and it lays to rest once and for
  17. > > all the religious wars over brace placement. OTOH, I've never even
  18. > > *seen* any Python. (Other than Monty.)
  19.  
  20. >No no no no no.  The reasons why this is a fundamentally flawed idea
  21. >are endless:
  22.  
  23. I'm not familiar with Python, but I'm familiar with Haskell, which also
  24. uses whitespace to structure code.
  25.  
  26. >linewrap,
  27.  
  28. This is not a problem in Haskell; you just need to make sure that
  29. you indent the wrapped part of the line, e.g.
  30.  
  31.     this is a very long statement of pseudo-haskell that doesn't quite
  32.         fit on one line
  33.  
  34. >tabs,
  35.  
  36. So disallow them!
  37.  
  38. >painful to automatically generate code,
  39.  
  40. In Haskell it is not painful to automatically generate code, because
  41. Haskell does not *require* the use of layout to indicate nesting;
  42. curly braces and semicolons can be used instead.  You can also
  43. mix the use of implicit nesting (via layout) and explicit nesting
  44. (via curly braces and semicolons).
  45.  
  46. >virtually impossible to stream-edit code,
  47.  
  48. Huh?  Why?
  49.  
  50. >proportional fonts,
  51.  
  52. Even proportional fonts don't have proportional whitespace!
  53.  
  54. >breakable v. non-breakable spaces of differing widths,
  55.  
  56. So just make sure the language only allows one type of space.
  57.  
  58. >difficulty of cut-and-paste,
  59.  
  60. Good!  Cut-and-paste reuse is the worst kind.  Programmers that would
  61. cut-and-paste without fixing the indentation should be taken out and
  62. shot.
  63.  
  64. Anyway, how difficult is it to learn the `block indent' command in your
  65. editor?
  66.  
  67. >impossible to use yacc-style tools,
  68.  
  69. This is not true; it's really quite easy to write a yacc parser for Haskell.
  70. You just need a tiny bit of cleverness in the lexer.  (Nothing as tricky
  71. as the feedback from parser to lexer required to parse C, for example.)
  72.  
  73. >difficult to read out over the phone,
  74.  
  75. You really want to read complicated code fragments over the phone?  Ugh!
  76. Use the fax!  Or email.  If you really must read things over the phone,
  77. then you can use the curly braces and semicolons format for that
  78. purpose.  (It's trivial for your compiler vendor to provide a tool to
  79. automatically convert code to that format.)  But anyway, I think this
  80. is such a rare activity that it is not the important thing to optimize;
  81. optimizing readability is much more important.
  82.  
  83. >hard to internationalize,
  84.  
  85. Why on earth is it hard to internationalize?
  86. I guess the ancient Egyption hieroglyph scribes didn't use spaces,
  87. but how many modern character sets don't include a space character?!?!
  88.  
  89. The notion of indentation still works fine even if you write your text
  90. right-to-left and bottom-to-top.
  91.  
  92. >sensitive to identity of newline character,
  93.  
  94. So?  Many, if not most, languages already have syntax that is sensitive
  95. to the identity of the newline character.  Examples include C, C++, Perl,
  96. Basic, Fortan, sh, etc., etc.
  97.  
  98. Try
  99.  
  100.     #include <stdio.h> main() { printf("hello world\n"); }
  101.  
  102. with your favourite C compiler!
  103.  
  104. >macros,
  105.  
  106. If you really must use syntax macros, then you can use the curly braces
  107. and semicolons method of specifying nesting within them.
  108.  
  109. But a much better solution is to not use syntax macros at all -- they
  110. cause a huge number of problems in practice.  If you do want macros,
  111. use something which works at a higher semantic level, such as lisp
  112. macros, C++ templates, or higher-order functions in Haskell.
  113.  
  114. >statements inside expressions, ...  
  115.  
  116. What does that have to do with anything?  Sounds just like another
  117. nesting construct to me.  I don't see why it would pose any problems.
  118.  
  119. >It is simply not a good idea, whitespace is too volatile to be a
  120. >syntactic marker, and counting spaces is too far removed from language
  121. >theory.
  122.  
  123. I respectfully disagree.  The idea is not fundamentally flawed.
  124. It works just fine in practice.
  125.  
  126. The only question is whether the resulting code is really more readable ;-)
  127.  
  128. --
  129. Fergus Henderson                 WWW: http://www.cs.mu.oz.au/~fjh
  130. fjh@cs.mu.oz.au                  PGP: finger fjh@128.250.37.3
  131.